In Java, a deployment descriptor is a configuration file for an artifact that is to be deployed, for example, to a container. The deployment descriptor may be an Extensible Markup Language (XML) document that describes the deployment settings of an application, a module, or a component. The deployment settings may be specific container options, security settings, configuration requirements, etc. At runtime, a Java server reads the deployment descriptor and acts upon the application, module, or component accordingly. Typically, Java components are compiled and packaged into one or more units for deployment, e.g., Java archive file (JAR), enterprise archive file (EAR), web archive file (WAR), etc. The package may include the compiled source code of the component and the deployment descriptor. Because deployment descriptor specifies metadata information as a file external to the respective compiled source code of the component, it can be changed without the need to modify the source code of the component. Nevertheless, to change the metadata information specified by the deployment descriptor, the package containing the deployment descriptor and the component needs to be unpackaged and repackaged after the deployment descriptor is modified.
Deployment descriptors may generate boilerplate code that may be redundant. In an effort to minimize boilerplate code, annotations are introduced in later versions of the Java Platform Enterprise Edition (e.g., Java EE 5). One advantage of annotations is that they reduce the amount of code a developer needs to write. Annotations provide a mechanism for associating Java classes, interfaces, fields, methods, etc., with metadata information. Annotations are considered, among other things, as an alternative to deployment descriptors required by earlier versions of Java EE or the Java Platform, Standard Edition (Java SE). As opposed to deployment descriptors, annotations maintain the metadata information as part of the program itself, e.g., as part of the source code of the component. For example, annotations may be included into the source code of a Java class to specify configurations of the Java class required at run time. Annotations, to be included into the deployment package, are compiled as part of the source code of the respective component. To modify the compiled annotations a possession of the source code is required to change to source code itself. In case where a customer of a software provider would desire to customize configurations, the consumer needs to either possess the source code (which is rare), or request the desired modification from the software provider. In any case, to modify annotations, the source code of the component needs to be modified, then recompiled (or rebuild), repackaged and redeployed. Such approach might be cumbersome, time consuming, and less scalable. Furthermore, because the aforementioned actions require a recompilation to modify the annotations, the approach is not performed dynamically, e.g., during runtime of the component.